Simulation for training in sinus floor elevation : new surgical bench model

Objectives: to describe a bench model (workshop of abilities) for sinus floor elevation (SFE) training that simulates the surgical environment and to assess its effectiveness in terms of trainees? perception. Study design: thirty-six randomly selected postgraduate students entered this cross-sectional pilot study and asked to fill in an anonymous, self-applied, 12-item questionnaire about a SFE workshop that included a study guide containing the workshop?s details, supervised practice on a simulated surgical environment, and assessment by means of specific check-lists. Results: Thirtiy-six fresh sheep heads were prepared to allow access to the buccal vestible. Using the facial tuber, third premolar and a 3D-CT study as landmarks for trepanation, the sinus membrane was lifted, the space filled with ceramic material and closed with a resorbable membrane. The participants agreed on their ability to perform SFE in a simulated situation (median score= 4.5; range 2-5) and felt capable to teach the technique to other clinicians or to undertake the procedure for a patient under supervision of an expert surgeon (median= 4; range 1-5 ). There were no differences on their perceived ability to undertake the technique on a model or on a real patient under supervision of an expert surgeon (p=0.36). Conclusions: Clinical abilities workshops for SFE teaching are an essential educational tool but supervised clinical practice should always precede autonomous SFE on real patients. Simulation procedures (workshop of abilities) are perceived by the partakers as useful for the surgical practice. However, more studies are needed to validate the procedure and to address cognitive and communication skills, that are clearly integral parts of surgical performance

Multilevel Contracts for Trusted Components

This article contributes to the design and the verification of trusted components and services. The contracts are declined at several levels to cover then different facets, such as component consistency, compatibility or correctness. The article introduces multilevel contracts and a design+verification process for handling and analysing these contracts in component models. The approach is implemented with the COSTO platform that supports the Kmelia component model. A case study illustrates the overall approach.Comment: In Proceedings WCSI 2010, arXiv:1010.233

Service Renaming in Component Composition

In component-based systems, the behavior of components is usually described at component interfaces and the components are characterized as requester (active) and provider (reactive) components. Two interacting components are considered compatible if all possible sequences of services requested by one component can be provided by the other component. This concept of component compatibility can be extended to sets of interacting components, however, in the case of several requester components interacting with one or more provider components, as is typically the case of cleint-server applications, the requests from different components can be interleaved and then verifying component compatibility must take into account all possible interleavings of requests. Such interleaving of requests can lead to unexpected behavior of the composed system, e.g. a deadlock can occur. Service renaming is proposed as a method of systematic eliminating of such unexpected effects and streamlining component compositions

Enhancing Dependability of Component-based Systems

International audienceWe present a method to add dependability features to component-based software systems. The method is applicable if the dependability features add new behavior to the system, but do not change its basic functionality. The idea is to start with a software architecture whose central component is an application component that implements the behavior of the system in the normal case. The application component is connected to other components, possibly through adapters. It is then possible to enhance the system by adding dependability features in such a way that the central application component remains untouched. Adding dependability features necessitates to evolve the overall system architecture by replacing or newly introducing hardware or software components. The adapters contained in the initial software architecture have to be modified, whereas the other software components need not to be changed. Thus, the dependability of a component-based system can be enhanced in an incremental way